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able part metadata that can be used for constructing distrib- 
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HIERARCHICAL METADATA STORE FOR required to facilitate this sharing. Such a store must support 

AN INTEGRATED DEVELOPMENT usage and access characteristics of a multi tool/multi user 

ENVIRONMENT environment and provide a flexible basis for capturing 

required semantic information. 
CROSS REFERENCE TO RELATED 5 fhc store must also define an overall information struc- 
APPLI CATION tm-e about applications under development, and organize it 
This appUcation is related in subject matter to our copend- ^ ^ way that offers the degrees of freedom required by 
ing U.S. patent application Ser No. 08/950,117, filed on Oct. today's applications. These degrees of freedom include 
14, 1997, for "An Object Oriented Framework Mechanism choices of targets, languages, component models. 
Providing Common Object Relationship and Context Man- distribution, etc. The IDE further needs to define a model for 
agement for Multiple Tools", the disclosure of which is sharing common application semantics among the cooper- 
incorporated herein by reference. tools, but at the same time allow individual tools to 

extend the shared information with private tool data. The 

BACKGROUND OF THE INVENTION model also need to "manage" programming "element" nam- 

, ^. . , ^ , ^ . 15 ing issues (naming scopes) across the various domains 

1. Field of the Invention ^^^.^^ ^^^^^ ^^^^^^ 

The present invention generally relates to the data pro- Therefore, an object of the present invention is to provide 

cessmg field, and more speafically to the provision of an ^ mechanism for organizing metadata in support of the 

integrated tool development enviromuent. development of complex enterprise applications by defining 

2. Background Description 20 ^ layered data model for handling application development 
Traditional tool development foUows the simple steps of metadata, addressing the various application degrees of 

creating the text-based source code, and then compiling and freedom within a single metadata store, 

executing the code on a specific platform. The increasing accordance with these objects, the present invention 

complexity of function and integration of tools over multiple provides a metadata container for common access tool data 

platforms means that tool development cannot generally be jn ^j, object oriented programming environment. The meta- 

performed by small groups of human developers. Often the data container has a hierarchical structure that consists of 

only way to produce a fiiUy functioning application is to sjjnpie constructed types containing subparts and encapsu- 

make use of specially-designed application development jated behaviour, components containing properties of a 

tools in order to build other tools. Today's applications are target language, and composed parts permitting partitioning 

built using a mix of low level tools such as source editors foj- distribution. 

and debu^ers, along with high level buildets of user , j^^^^^^^ .^^^ ^ ^^^^^^^ ^^^^^ 

uiterfac^^ata access, distnbuUon support, and code gen- ^^^^^ ^^^^ j^^, ^^^^ ^ ^^^^^^^^ programming 

erators. The applications built m such environments are . . ... c ■ 1 u 1 j c ■ 

xus. *^^^v«.^v^4a^ ou** ^ s.^ ^ environment consisting of a smcle base class defimng com- 

targeted to run m a multiplicity of execution environments, uu* c i 4-iU*iJi j 

^ . . , , . J. 35 nion behaviour for elements m the tool data, and separate 

on vanous hardware platforms, supporting many distnbu- u * * 1 t. • u • • u • r *u • 1 u 

. . , % , ' ^* T< 1 • abstract class hierarchies, inhenting from the single base 

tion mechanisms and data access mechanisms. Developing 1 *j£ j *- 

. , ^„ ■ class, to define name scope and contamment tor tool data, 
such applications m the current state of the art requires the 

use of multiple different tools for multiple different vendors, BRIEF DESCRIPTION OF THE DRAWINGS 
each solving a piece of the over all puzzle. 

^ ^0 The foregoing and other objects, aspects and advantages 

The ideal is to provide an integrated development envi- .,, . . * , , , J c ^^ j . •? j 

* /TrM-\ uu-f A u*i will be better understood from the following detailed 

ronment (IDE) m which miormatioQ provided by each tool . ... . c j u * r*u ■ *■ 

J . ^ J 1 ^ t. u J ^ 1 description of a preferred embodiment of the mvention with 

dunng program development can be shared with other tools, r . ^t. j • l- t. 

."f , . J • .1. J 1 ^ a J reference to the drawings, in which: 

particularly those bemg used m the same development effort, * 

to avoid duplication and inconsistent interface and function P'^* ^ is a schematic drawing illustrating categories of 

operations. Currently available development tools address metadata layered "parts" according to the preferred embodi- 

only a small subset of this requirement. They typically focus °f invention; and 

on a source- level, single targeted application, and use a FIG. 2 is a tree diagram illustrating the model layer 

simple file system folder/directory model for their informa- hierarchy according to the preferred embodiment of the 

tion. invention; 

Where the application development tools are tightly and 

integrated, they can often use cross reference tables to share FIG. 3 is a class diagram, expressed in C++, of an IDE 

information about the program under development. How- element base class, according to the preferred embodiment 

ever in an incremental development environment, the tables of the invention, 

can be out of synch with the source code, and frequently cc 

contain less informaUon than impUed by the source code. DETAILED DESCRIPTION OF A PREFERRED 

Also, any tool not closely integrated (and this is often the EMBODIMENT OF THE INVENTION 

case with tools from different manufacturers) will have to The preferred embodiment has been implemented as an 

parse the source or the tables, provided the programming opeQ;4atacmodelahat;:pro.\ides sourc^ ^ 

language is not a barrier. This parsing exposes the tool either eo dSleiEmedi^te^fomTacces^^ 

to parsing differences or internal table definitions. m^tools^haXAiw^ The dala moM 

/iTlan^age independent which, allo.ws^cross systetnsourc'^" 

SUMMARY OF THE INVENTION /sli'arinl;m raoddcould.be use^to drive.axode-gene^ator/ 

One of the key problems that needs to be addressed during In the preferred embodiment, the data model provides a 

construction of an IDE for a complex application is the 65 metadata store in support of a tool integration framework 

ability of the various IDE tools and components to share which is fully described in our concurrently filed, copending 

information in a meaningful way. An "information store" is application Ser. No. 08/950,117, titled "An Object Oriented 
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Framework Mechanism Providing Common Object Rela- A degenerate case of the generalised parts are various 

tionship and Context Management For Multiple Tools" types supported by the data model. These types are further 

(IBM Docket No. CA997-002). specialisations of generalised parts that capture or cncapsu- 

In order to handle the requirements of the range of late the following concepts: fundamental types (eg. int, char) 

applications, from basic source programming to component 5 represented by Primitive Types 4; records are repre- 

based visually constructed applications, the data model of sented by Structs 3; overlaid memory structures are repre- 

the present invention provides a shared metadata store in sented by Unions 7; named cardinal values are represented 

which the development information is layered. Each layer by Enumerations (Enums) 6; and aliased parts are rcpre- 

defines the common behaviour required at that level. Tools sented by T^pe Definitions (TVpe Def) 5. 

using the model start with a behaviour at a given layer and Component parts 8 are base name parts with the addi- 

extend it as appropriate for the particular tool. lional support of a component model. A component part, 

The data model captures information about various "ele- regardless of its ultimate source language implementation, 

ments" required during the development of an application. ^^^^ external behaviour as a set of attributes which are 

This includes information about the logical pieces of an "properties", events raised by the part and actions 

overall application, such as folders, files and appUcation ^^^^^ are extemaUy tnggerable behaviour. Tlie data mod^^ 

parts. At Z highest level, the data model generally defines ^^P^^^^^ this mformation as a component part and allows he 

f. L i_ * • J ^ u - J generation of the appropnate target component model (eg 

the common behaviour required to be recogmzed as an JaVABEANS™, IBM® VisualAge VBE model, etc.) 

element within the mtegrated development environment. (javaBEANS is a trademarkof Sim Microsystems, Inc. and 

ITiismcludes^theabihty for rendering the element, exposing jbM is a registered trademark of International Business 

Its content (if appropnate), as well a triggering any of its Machine Corp.) Within an IDE, this typically represents the 

actions. i^y^i support used by higher order "builder" tools. Com- 

This is roughly equivalent to other currendy available pooent parts are referred to within the data model as "builder 

application development information stores that map to a file consumable" parts, in relation to FIG. 2. 

system (source files and directories/folders). However the Partitionable containers 9 are component parts that expose 

data model of the invention is further extended into key 25 part of their internal behaviour to a level that allows repar- 

^rc^s: titioning of the part for distribution. Through the data model, 

1. recognition of namespaces as distinct from folder these parts expose interactions among their aggregated 
containment; and subparts, as well as interactions across parts. This level of 

2. refinement of the application "part" concept into dis- information is used to capture the application distribution 
tinct part layers. 30 structure regardless of the target distribution mechanism. 

Rather than leaving it to the developer to recognize Depending on its specific requirements, a tool selects the 
project folder containment and application part naming at appropriate level of parts support to store its tool part 
the source or force the naming relationships to be the same metadata within the data model. Shared behaviour is inher- 
as the folder containment, the data model of the present ited from the data model, and the tool adds it own extensions 
invention defines name scope as a "parallel" set of relation- 35 as appropriate. Typically, these extensions are opaque tool- 
ships to that of containment. This allows, for example, a part specific properties. For example, this structure allows a data 
containing a C++ class A::B::C to be properly defined as a access part which is a component part containing informa- 
series of nested naming scopes, while at the same time tion about access to a data base, to be consumed by a 
allowing the same part to be used (through containment or user-interface (Ul) builder producing a UI part. The UI 
Unking) within several project folders. 40 builder is a composed part containing the data access part 

The data model of the invention supports application and UI controls. This can subsequently be partitioned into a 
definition and assembly from parts. According to the client part (UI and server call) and server part (server logic) 
invention, a part is a self contained piece of an overall and access to data base. This is all done by editing the data 
application that is distinct from the source files that contain model information. The same data model information can be 
the source code for the part. Depending on the programming 45 used to generate a JAVA*^" Bean with JAVA™ remote 
environment, a part may in fact reference several files (for method invocation (RMl) call to server and JAVA™ Data- 
example in C++, the .hpp and .cpp files) but a part is not a base Connectivity (JDBC™) access to data base, or a C++ 
file container. Within the data model of the invention, a part client with DCE access to a server with a local data base 
is a separately editable piece of application definition (JDBC is a trademark of Sun Microsystems, Inc.). 
(metadata) distinct from any source files that may be asso- 50 The preferred embodiment is implemented in an object 
ciated with the part or generated from the part definition. As oriented programing hierarchy which facilitates the sharing 
wiU be discussed in more detail below, within the data model of parts through inheritance. FIG. 2 illustrates an approach 
of the invention, all parts are named and name scoped. Apart to data model layers according to the preferred embodiment 
(based on its implementation) may itself be a name scope for providing a class definition at each layer and illustrating how 
other parts, as in, for example, C++ nested classes. 55 the class of metadata, at that level in the hierarchy, can be 

The layering approach to a metadata store is schemati- used by tools, 

cally illustrated in FIG. 1. The semantics of a part 1 are The most abstract base class, the IDE Element 20, is 

layered in a spectrum in the data model from parats used by provided for the implementation of an IDE tree view. Using 

general use tools to parts used by increasingly specialised mostly pure virtual methods, it permits the tree view to 

tools. At the general end of the spectrum, Generalised Parts 60 display the contents of the model, launch actions against its 

2 are base parts corresponding to the semantics of a con- elements (nodes), and attempts structural changes against 

structed type within the target language. The list of genera- the hierarchy without regard to the content details. Success 

Used parts include subparts and encapsulated behaviour such of these operations (especially structural changes) depends 

as methods and inheritance. Typically, these correspond to a on the supported semantics of the individual tree element 

class definition for object oriented languages such as C++ 65 derivations. 

and JAVA™, or to some form of a structure, such as in The common behaviour of rendering of tree nodes is 

COBOL (JAVA is trademark of Sun Microsystems, Inc.). defined so that each element within the tree view wiU show 
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its name, icon, indication whether element is owned or cies have changed. The model provides a method to manage 

linked, and an indication whether the element can be further this indication shown in FIG. 3. 

expanded, 4. associated file operation: the model makes the distinc- 

The basis for expanding branches of the tree view is the tion between contained and associated files. A contained file 

ability to list the contents of any one IDE element as its 5 is simply an IDE element that is structurally related to its 

contained element. Thus, the IDE Element base class 20 container. An example is the source files contained within a 

provides a common behaviour to expose content. This is project group folder. Contained files are manipulated using 

illustrated, in the preferred embodiment, in the sample C++ the content and structural operations discussed earlier in this 

header file for an IDE Element base class set out in FIG. 3. section. An associate file is a file reference that is required 

Each derived IDE element determines what constitutes its lO example of an associated file or header files required in order 

content. Unlike most other relationships supported within to use a part, or source files generated from a group or a part, 

the model, the "contains" relationships have a requirement When most cases these are not actuaUy contained within the 

for supporting direct access to its element by name, as well element with which they are associated, 

as providing cursor based access that maintains ordering. At the next level of abstraction are the Containment Scope 

This is required because the tree view is expected to allow 15 22 and Name Scope 24 base classes. As mentioned above, 

the nodes within the tree to be reordered using drag and drop containment and part naming are parallel, and therefore, 

operations or the selection of reordering actions. The relative independent relationships. 

element order is maintained within the model. A specific On the containment scoping side, the base class 22 

example of this is a visual builder pallet containing pallet represents a generalized grouping construct. In its default 

categories, each of which contains parts available to the 20 form, it allows an arbitrary coUection of groups, parts and 

builder. Frequently used items would be expected to be files that can be owned or linked. Also by default, its content 

placed at the top of the list to reduce the need for scrolling. can be "edited" through the tree view or a tool action. This 

The model also provides a set of methods at this level of is a general "folder" 40 construct within the IDE. 

abstraction that allow modifications to the tree structure The base Name Scope class 24 defines support for nested 

without regard to element details. The success of these 25 name scopes within the preferred embodiment model. Its 

operations is determined by the derived implementations. primary intent is scoping of name parts. The Name Scope 

There are two mechanisms for constructing container rela- Folder 26 and Named classes are used to construct the 

tionships: hierarchy reflecting the definitional scopes of the parts. This 

1 . Ownership relationships indicating aggregation of the hierarchy is parallel to that of containment, to allow name 
sub elements within the subject parts. Owned elements are 30 scoping to be independent of part containment, 
destructed if orphaned by a parent; and The Namescope Folder class 26 is in all aspects identical 

2. Reference relationships indicating soft links or shadow to the Containment Scope class 22, except it also defines a 
links to a sub element owned or aggregated elsewhere within name scope. Namescope Folder 26 is to allow name scope 
the tree. other than name groups and the derivations and parts in their 

In all cases, a removal action on one element propagates 35 derivations. This is a general names based construct within 

the removal action across ownership relationship but not the IDE. 

reference relationships. That is owned elements are Scoped names are constructed by assembling a nested set 

destructed but in the case of linked elements only the link is of scopes using the group and part constructs. Model, the 

removed. It should be noted that the data model does not singleton basis of the structure, plays the role of the global 

enforce a single owning parent rule, although a great major- 40 naming scope. Constructors are provided on group and part 

ity of owning relationships are expected to be of this type. derivations that allow specification of the parent name scope 

In an owning relationship, the child is destructed when any for the item being constructed. If a name scope for these 

parent is destructed or when the child is explicitly orphaned objects are not specified the constructed objects are defined 

by any owning parent. at a global scope, that is created below model in the name 

Since derived implementation may reject attempt to 45 scoping hierarchy, 

change the contents of the tree nodes, methods are provided In general, tree nodes also act as local name scopes for the 

to check if the desired operation is allowed. Even if the immediate children they contain. By default, children of an 

operation is allowed it may still fail for other reasons. The element must have unique names. Since part names are 

decision to accept or reject a content action is up to the globally unique (under the name scoping mechanism), the 

object that is the recipient of the content, that is the parent 50 default model implementation will allow a part to be created 

object would be asked for permission not the child object. independent of any non-part construct that may exist with 

In the prefened embodiment, the IDE Element base class the same name but will not allow a part to be stored in an 

20 provides additional common behaviour, including: element container if the container already has a non-part 

1. action support: the model provides a mechanism for child with the same name. 

triggering edit actions against the model objects. The term 55 Continuing in the Name Scope hierarchy, the Named Part 

"edit" simply means any tool specific action. Each tool is class 28 represents a generalized part construct 44. By 

expected to provide an implementation of the edit methods default, its content is editable only via an explicit tool action, 

in their concrete class derivations. The part class is not a folder, although it may be defined as 

2. code generation support: each element can cause source an aggregate of sub-parts. 

output to be generated for the model metadata. A default 60 The Named Part class models are based constructed type, 

implementation of generate () is to simply return. If output and permits the data model to capture information about 

must be produced, the derived implementation need to over model defined attributes and properties, inheritance, data 

ride the generate ( ) method. This generate () is a context member and sub-part aggregation, and externally triggerable 

sensitive method. behaviour or methods. All parts can act as name scopes for 

3. "dirty** part support: an IDE element can be marked by 65 other parts. 

a tool as being "dirty". This indicates that the source code for As mentioned above. Primitive Part 30 is a degenerate 

the element must be regenerated because it or its dependen- case of the base Named Part 28. Primitive Part 30 are various 
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primitive types such as integer, character, float. Boolean, 
supported by the data model. 

The Builder-Consumable Part class 32 implements 
semantics of a compoDcnt part. These btiilder parts are 
consumable by the visual compositioQ editor (graphical s 
composer). They are defined in terms of attributes, events 
and actions. At generation time, Builder-Consumable parts 
feature maps to the appropriate target component model 46. 

The Builder-Composed Part class 34 is a partition class 
that defines the semantics of a partitionablc composed part, lo 
as distinct from a distributable part. It should be pointed out 
that a part is distributable if builder tools are allowed to use 
a proxy to access a remote instance of the part. In the data 
model, this is indicated by a part property. A part is parti- 
tionable if distribution support can effectively rearrange the 15 
part content across two or more parts. Concrete parts derived 
from this class map to composed parts 48 and are partition- 
able by distribution support. 

Local associations among a part's sub-parts arc captured 
within the part definition. They represent sub-part interac- 20 
tions. Methods are provided to handle the repartitioning of 
a part which occurs by redeploying a sub-part from one part 
to another. If this redeployment is successful, a distributed 
association between the parts is created. These represent 
distributed cross part interactions between sub parts of 25 
different parts. 

A final base class is the File Reference class 36 which 
represents a generahzed file reference construct. It is a 
symbolic pointer to a file item 50 in the file system. 

Embodiments of and modifications to the described 30 
invention that would be obvious to those skilled in the art are 
intended to be covered by the appended claims. 

We claim: 

1. A computing system for storing and retrieving metadata 

in a container for common access tool data in an object 35 
oriented programming environment, having a hierarchical 
structure, comprising: 

means for storing computer readable data and computer 
code; 

a first code section of said computer code comprising a 
plurality of simple constructed types that contain sub- 
parts and encapsulated behaviour; 

a second code section of said computer code comprising 
a plurality of components that contain properties of a 
target language; 

a third code section of said computer code comprising a 
plurality of composed parts that permit partitioning for 
distribution; and 

means for processing said first, second and third code 
sections stored in said storage means, enabling a plu- 
rality of computer implemented design tools to share a 
representation of a design, implementation and distri- 
bution of an application, wherein said data is organized 
in said storage means for direct manipulation by design 55 
tools. 

2. A computing system for storing and retrieving metadata 
for common access tool data in an object oriented program- 
ming environment, comprising: 

means for storing computer readable data and computer 
code; 

a first code section of said computer code comprising a 
single base class defining common behaviour for ele- 
ments in the tool data; 

at least one additional code section of said computer code, 65 
each said at least one additional code section compris- 
ing a separate abstract class hierarchy, inheriting from 
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the single base class, to define name scopes and con- 
tainment for the tool data; and 
means for processing said first code section and said at 
least one additional code section, said code sections 
stored in said storage means, enabling a plurality of 
computer implemented tools to access common tool 
data defined by said code sections. 

3. A metadata store, according to claim 2, wherein the 
abstract class hierarchy to define name scopes comprises: 

a part class representing a generahzed part construct 
adapted to contain subparts and encapsulated behav- 
iour. 

4. A metadata store, according to claim 3, wherein the 
abstract class hierarchy to define name scopes comprises: 

a component class adapted to implement properties of a 
target language. 

5. A metadata store, according to claim 3, wherein the 
abstract class hierarchy to define name scopes comprises: 

a partition class adapted to contain definitions of part 
partition semantics. 

6. A metadata store, according to claim 3, wherein the 
abstract class hierarchy to define name scopes comprises: 

a component class adapted to implement properties of a 
target language. 

7. A metadata store, according to claim 2, wherein the 
abstract class hierarchy to define name scopes comprises; 

a component class adapted to implement properties of a 
target language, 

8. A metadata store, according to claim 2, wherein the 
abstract class hierarchy to define name scopes comprises: 

a partition class adapted to contain definitions of part 
partition semantics, 

9. A metadata store, according to claim 2, wherein the 
abstract class hierarchy to define name scopes stratifies the 
tool data into a layered structure, comprising: 

simple constructed types that contain subparts and encap- 
sulated behaviour; 

components that contain properties of a target language; 
and 

composed parts that permit partitioning for distribution. 

10. A computer implemented method for storing metadata 
for common access tool data in an object oriented program- 
ming environment, said method comprising the steps: 

identifying a single base class, defining common behav- 
iour for elements in the tool data; 

identifying at least one separate abstract class hierarchy, 
inheriting from said single base class, to define name 
scopes and containment for the tool data; and 

representing said identified base classes and said at least 
one class hierarchy in object oriented computer code, 
enabling a plurality of computer implemented tools to 
access common tool data as represented in said com- 
puter code. 

11. A computer implemented method as recited in claim 

10, wherein said abstract class hierarchy to define name 
scopes comprises: 

a part class representing a generalized part construct 
adapted to contain subparts and encapsulated behav- 
iour. 

12. A computer implemented method as recited in claim 

11, wherein said abstract class hierarchy to define name 
scopes comprises: 
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a component class adapted to implement properties of a 
target language. 

13. A computer implemented method as recited in claim 
11, wherein said abstract class hierarchy to define name 
scopes comprises: 5 

a partition class adapted to contain definitions of part 
partition semantics. 

14. A computer implemented method as recited in claim 
11, wherein said abstract class hierarchy to define name 
scopes comprises: 10 

a component class adapted to implement properties of a 
target language. 

15. A computer implemented method as recited in claim 
10, wherein said abstract class hierarchy to define name 
scopes comprises: 

a component class adapted to implement properties of a 
target language. 

16. A computer implemented method as recited in claim 
10, wherein said abstract class hierarchy to define name 
scopes comprises: 

a partition class adapted to contain definitions of part 
partition semantics. 
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17. A computer implemented method as recited in claim 
10, wherein said abstract class hierarchy to define name 
scopes stratifies the tool data into a layered structure, com- 
prising: 

simple constructed types that contain subparts and encap- 
sulated behaviour; 

components that contain properties of a target language; 
and 

composed parts that permit partitioning for distribution. 

18. A computer readable medium containing computer 
code for storing metadata for common access tool data in an 
object oriented programming environment, enabling a plu- 
rality of computer implemented tools to access common tool 
data as represented in said computer code, the code imple- 
menting the steps of: 

identifying a single base class, defining common behav- 
iour for elements in the tool data; and 

identifying at least one separate abstract class hierarchy, 
inheriting from said single base class, to define name 
scopes and containment for the tool data. 

M * * * * 
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